Many different types of user-interaction and processing system exist. They are used in a host of diverse industries for many different purposes. Most of these are directed towards facilitating user interaction with a distributed system often in dispersed geographic locations to enable a function to occur. For example, different transport systems may have different user tokens (tickets) to enable a user to travel geographically between two different locations. Similarly, automated biometric identity systems exist to verify the identity of a person carrying a biometric passport before granting entry into a different country. Also transactions in goods and services using a bank-issued user token (payment card for example) can also be carried out in geographically-spaced apart locations with central authentication of the user token presented by the user to support the desired transaction.
Other types of system enable user interaction to be monitored and tracked to provide data relating to user behaviour with a geographically distributed system to be captured.
To encourage this type of behaviour, users can be provided with user tokens which accrue benefits for repeated use. One example of this is a loyalty card programme system which allows retailers to reward loyal customers. In essence, when a purchase is made and the relevant loyalty card is presented, a reward (for example points) is given to the customer that may be relative to the cost of the purchase, or otherwise be linked to the purchase transaction. Over time a customer can amass enough points to be able to ‘spend’ some or all of their points according to an equivalent monetary value or redeem them against certain items.
Given the number of different types of system which are present in even just one type of industry there is a desire to aggregate these different systems to prevent the user from having to carry a multitude of different types of user token to facilitate interaction with the different types of systems they will need to interact with each day. One way in which the different types of systems can be integrated is by the integration of the system's back end, which can reduce processing issues and speed up the reconciliation of interactions with the system. However, whilst such systems simplify the processing task for the service provider, they do not solve the problem from the user's perspective.
Other systems impose a standard to the data presentation format on the user token. For example in a payment token (for example a credit/debit bank card) the location and format of relevant data provided on the user token can be standardised such that a myriad of different devices can be configured to the standard to read that data present on the token and identify not only the type of user token but also specific information unique to the owner of that user token, for example a user identifier. Looking more closely at this data presentation format standardisation and referring to FIG. 1, it can be seen that a payment card 10 has a standardised layout. All payment cards have the same dimensions and include both a long Primary Account Number (PAN) 12 and an expiration date 14, signifying the month and year in mm/yy format after which the card 10 ceases to be valid and can no longer be used. The PAN 12 always extends across the card 10 just beneath the central longitudinal axis of the card 10 and comprises a sequence of 16 numbers split into 4 sections. The provider of the payment card 10 can be identified from the first few numbers of the PAN 12. The expiration date 14 is found beneath the PAN 12. All payment cards conform to this standard. Payment cards may also incorporate a cardholder name 16, a bank name 18 and a chip 20 among other information, though these can vary in operation and data presentation for example location on the payment card 10.
The standard layout of payment cards in this way allows for swift recognition of a payment card in many different types of systems which provide goods and services for example a car-park ticket payment machine or a general a point of sale terminal at a retail outlet. The PAN and expiration data, along with the chip and layout are easily recognisable in an image of this type of user token in order to identify the user token as a payment card. This is an example of what is called a ‘common format’ for presentation of the data relating to the user token, namely one that does not change between different systems and so is easy to read.
However, of the other types of systems for which user tokens are necessary, there are a large variety of different formats used because they relate to independent systems that were never designed to work together. An example of this is a loyalty program user token and system described above. This type of user token has what is termed an ‘uncommon format’ namely one in which each different type of user token presents data in a manner which is different for each different type of system, making it very difficult for a single system to read all of the different types of user tokens.
In these system a single user may have to carry a large number of loyalty cards with them at all times. This inconvenience has led to the development of software applications that allow a user to view their loyalty cards and points balances in a digital wallet system, for example on a smartphone. These applications therefore reduce the number of cards it is necessary for a user to carry at any one time to those that are supported by the digital wallet. Thus, loyalty cards can be replaced with a computing device, such as a smartphone or tablet as an aggregator of these user tokens.
Typically, these applications require a large amount of manual data input prior to use that is time consuming and so a deterrent to the user. If data input to the application is too onerous, some users may not engage with the application fully, and will not gain the full benefit of the application and of their chosen loyalty card programmes. The loyalty scheme information to be manually inputted is likely to be both lengthy and numerical, and this introduces a potential for human error. Entering a wrong number may lead to errors in data retrieval, more frustration and time spent inputting the data, or, in a worse case, points earned by the user being transferred to a stranger.
These applications also require the user to present the device on which the application is running (and on which the data associated with the relevant loyalty scheme is stored) at the point of sale in order to accumulate loyalty points. While the number of cards a user must carry is thereby reduced, the user is still obliged to present a barcode or other identifier on the device to gain loyalty points. In the event that the application is not accessible, no loyalty points can be gained and the system cannot track the user interaction which is one of the primary functions of the system.
It is against this background that the present invention has been devised.